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(54) Secure database 

(57) A secure database system comprises a server 
having a database including at least one personal infor- 
mation table and at least one further table containing 
information relating to the persons whose details are 
stored in the personal information table. The keys of the 
tables in the database are unrelated, so that it is impos- 
sible to determine solely from information in the server 
which record in the further table corresponds to which 



record in the personal information table. Thus, even if a 
hacker obtains access to the database, the hacker will 
not be able to relate information in the different tables. 
Each legitimate client uses an encryptkxi process to 
convert a personal identifier value, which identifies the 
record relating to a partk:ular person in the personal in- 
formation table, into a pseudo-identifier value, which 
identifies a record relating to the same person in the fur- 
ther table. 



Patient 

Patient <pk> 
Name 



User 

User <pk> 
Name 



CarePericxf 
CarePeriod <pk> 
Patient <fk> 
UserPID 
DateFrom 



Registration 
Registratton <pk> 
Patient PID 
UserPICX . 
DateIn 



Appointment 

Appointment <pk> 

Registratk>n <fk> 

UserPID 

Date 

Time 



1^ 
(D 

00 
00 



UJ 



FIG. 2 



Medication 



Medication <pk? 
Registratton <fk> 
UserPID 
Time 



PatlentNote 



PatlentNote <pk> 
Registration <(k> 
UserPID 
FreeText 



Printed by Jouvo, 75001 PARIS (FR) 



1 



EP 0 884 670 A1 



2 



Description 

Background to the Invention 

This invention relates to secure databases. 

Many countries have legislation for controlling the 
way in which personal data nnay be stored and used on 
computer systems. For example, the Dutch Personal 
Data Registration Act ("Wet Persoonsregistraties") de- 
mands (among other things) that the database must be 
secured against hackers who have succeeded in getting 
unauthorised access to the database despite all security 
applied to it. However, it has been found that conven- 
tional database systems do not satisfy this requirement. 
For example, in conventional hospital information sys- 
tems, if a hacker gains access to a medical history 
record, the hacker can obtain the patient's key from this 
record and use this key to access any other records con- 
taining information about the same patient, such as the 
patient's name and address. 

The object of the present invention is to provide a 
way of overcoming this problem. 

Summary of the Invention 

According to the invention a computer system com- 
prises: 

(a) a server having a database including at least one 
personal information table and at least one further 
table containing information relating to persons 
whose details are stored in the personal information 
table; and 

(b) a plurality of clients, for accessing sakJ data- 
base; 

(c) said tables in said database having keys that are 
unrelated to each other, whereby it is impossible to 
determine solely from information in the server 
which record in said further table corresponds to 
which record in said personal Information table; and 

(d) each client including an encryption process for 
converting a personal identifier value, which identi- 
fies a record relating to a particular person in said 
personal information table, into a pseudo-identifier 
value, which identifies a record relating to the same 
person in sakd further table. 

It can be seen that, even if a hacker obtains access 
to the database, the hacker will not be able to relate in- 
formation in the different tables. In a hospital information 
system for example, if a hacker obtains access to a med- 
ical history record, the hacker cannot relate this record 
to a particular patient 

Brief Description of the Drawing 

Figure 1 is a block diagram showing a computer 
system incorporating a secure database. 



Figure 2 shows a skeleton model of the database. 
Description of an Embodiment of the lnventk)n 

B One embodiment of the invention will now be de- 
scribed by way of example with reference to the accom- 
panying drawings. This consists of a hospital records 
system which stores informatbn about patients and 
their treatments, and whbh can only be accessed by au- 

10 thorised users, such as doctors, nurses and administra- 
tors. However, it will be appreciated that the invention 
can also be used in other applbatkxis where there is a 
need to protect personal data. For example, the inven- 
tion could also be used in an insurance company data- 

is base for storing personal data about customers and de- 
tails about their claims. 

Overall view of the system 

^ Referring to Figure 1 , this shows a distributed com- 
puter system comprising a server 10 and a number of 
clients 11, interconnected by a network 12. The server 
is a central hospital computer, and the clients are per- 
sonal computers (PCs), located on individual users' 

2S desks. The server 10 runs a database application 13. 
which may be any database system; for exsimple, it may 
be an Oracle database. Each client 11 runs a client ap- 
plk:ation 14. whk:h enables an authorised user to com- 
municate with the database, and to access data from it 

30 Referring to Figure 2, the database 13 holds a 
number of tables. Each of these tables has a primary 
key (indicated by "pk"), whrch un'quely identifies each 
record in the table. This primary key is a numeric figure, 
starting with 1 (one) for the first record wrrtten in the table 

35 and incremented by 1 (one) for each subsequent record 
inserted into that table. Some of the tables also include 
foreign keys (Indicated by tk"), which identify connec- 
tions between the tables. 

There are two groups of tables. The first group con- 

40 tains personal data about patients and users, and the 
data defining the periods of care. Only the data in this 
group is required in order to establish if a user is allowed 
to access the records for a particular patient. This group 
comprises the following tables: 

45 

Patient Personal, non-medical data about indi- 

vidual patients, such as the patient's 
name, address and telephone number. 

so User Information about authorised users of 

the system. The information includes 
such things as name, login name, and 
doctor's specialism. 

5S Care Period Information about which users are cur- 
rently responsible for the care of individ- 
ual patients. 
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The second group of tables holds medical data. It 
consists of a largo nunnberof tables, each of which holds 
one and only one group of facts. Some examples of ta- 
bles in this second group are as follows: 

Registration Information at>out registration of indi- 
vidual patients. There Is one row in 
this table for each patient currently un- 
der active care. 

Appointment Information about appointments that 
have been arranged for individual pa- 
tients. 

Medication I nf ormation akxDUt medication that has 
been prescribed for individual pa- 
tients. 

PatientNote Free-text medical notes on individual 
patients. 

Each of the tables in this second group has a pri- 
mary key which is in no way related to the primary keys 
of the patient or user. Therefore, even if a hacker man- 
ages to obtain access to one of these tables, it is not 
possible for the hacker to relate the medical data to a 
particular patient or user. 

To enable authorised users to relate the inforrr^tion 
in this second group of tables to the patients or users, 
the system uses so-called pseudo-identifiers (PIDs). 
The PIDs are stored in extra columns of the tables. The 
PID values are calculated from the patients' and users' 
primary keys, using a cryptographic algorithm. The cryp- 
tographs algorithm is available only on the clients; the 
algorithm is not recorded in the database, and so cannot 
be discovered by a hacker who gains access to the serv- 
er. The algorithm uses a nnaster encryption key, which 
is different for each hospital. 

The PID values are calculated using a different en- 
cryption protocol for each PID in each table. This is 
achieved by assigning a unique identifier number 
nr„PID to each PID in each table, and using this number 
as an input parameter for the cryptographic algorithm. 
In other words, the encryption algorithm for a particular 
PID uses the following three parameters: 

- the primary key being encrypted, 

- the hospital's master encryption key. 

the unique identifier number nr_PID for the PID. 

Thus, it is guaranteed that records relating to the 
same patient have different PID values in different ta- 
bles, and records with the same PID in different tables 
do not relate to the same patient. 

For example, in the database of Figure 2, unique 
identifier numbers nr.PID may be assigned to the PIDs 
as follows: 
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Free-text columns in the database, such as in the 
PatientNote table, present a particular problem, since a 
user is free to put any text in these columns, and may 
therefore include the patient's name. This would be of 
great assistance to a hacker. This problem is overcome 
by storing such free text in encrypted form, using an en- 
cryption algorithm resident on the client. 

Login 

This section describes the operatk>n of the system 
when a user logs in. 

The client application first prompts the user to enter 
his or her login name and password, and sends a login 
message to the database application. When the data- 
base applk^ation receives this message, it authenticates 
the user. Techniques for authentk;atkxi of users are well 
known, and so will not be described in any further detail. 

Assuming that the user has been correctly authen- 
ticated, the database applicatbn then searches the Us- 
er table, to find the record that matches the user's login 
name. From this record, the database application Ob- 
tains the user's primary key. 

The client applicatk>n then encrypts the user's pri- 
mary key, using the appropriate nr.PID (34 for exampje) 
as a parameter, to generate a user PID value for access- 
ing the CarePeriod table. The PID is sent to the data- 
base application. 

The database appltcatkMi then searches the 
CarePeriod table, to find all rows containing this PID. 
This identifies all the patients currently in the care of this 
particular user. The database application then uses the 
patient keys from these rows to access the correspond- 
ing rows of the Patient table. The patients' personal de- 
tails are read from the Patient table, and are retumed to 
the client application, where they are displayed to the 
user. 

Medication table 

This section describes the operation of the system 
when a user wishes to obtain details of a particular pa- 
tient's medication. It is assumed that the user has 
logged in to the system and has obtained the patient's 
primary key as described above. 

The client application encrypts the patient's primary 
key, using the appropriate nr_PID (47 for example) as a 
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parameter, so as to generate a patient PID value for ac- 
cessing the Registration table. The patient PID is sent 
to the database application. 

The database application searches the Registration 
table to find the row that contains this patient PID value. 
It then uses the Registration key from this row to access 
the corresponding row in the Medication table. The med- 
ication record of the patient is then read from this row, 
and Is returned to the client application, for displaying 
to the user. 

Appointment table 

This section describes the operation of the system 
when a user wishes to obtain details of a patient's ap- 
pointments with a particular doctor. It is assumed that 
the user has logged in to the system and has obtained 
the patient's prinnary key as described above. 

The user primary key for the doctor is first read from 
a look-up table into the client application. 

The client application then encrypts the patient pri- 
mary key, using the appropriate nr_PID (47 for example) 
as a parameter, so as to generate a patient PID value 
for accessing the Registration table. The client applk:a- 
tion also encrypts the user primary key. using the appro- 
priate nr^PID (23 for example) as a parameter, so as to 
generate a user PID value for accessing the Registra- 
tion table. The calculated PID values are sent to the da- 
tabase applicatbn. 

The database applk^tion then searches the Regis- 
tration table, to find a row containing both of these PID 
values. It then uses the Registration primary key from 
this row to access the corresponding row in the Appoint- 
ments table. Details of the appointment are then read 
from this row, and retumed to the client application, for 
displaying to the user. 

PatlentNote table 

This section describes the operation of the system 
when a user wishes to view a free-text note relating to 
a partbular patient. It Is assumed that the user has 
logged in to the system and has obtained the patient's 
primary key as described abco/e. 

The client applicatk)n first encrypts the patient pri- 
mary key, using the appropriate nr_PID (47 for example) 
as a parameter, so as to generate a patient PID value 
for accessing the Registration table. The PID is sent to 
the database application.' 

The database application then searches the Regis- 
tration table, to find the row that contains this patient PID 
value. It then uses the Registration primary key from this 
row to access the corresponding row in the PatlentNote 
table. This row contains the (encrypted) free-torm text 
notes relating to the patient, and is retumed to the client 
application. The client appKication then decrypts the 
notes, and displays them to the user. 

The user can also update the text, or create new 



text, using a conventional worri processor. The client ap- 
plication encrypts this text, and sends it to the database 
applicatkjn, for writing into the PatlentNote table. 



Preferably, all traffic over the network 12 is encrypt- 
ed, to protect it against eavesdropping. It should be not- 
ed that this encryption is addrttonal to the encryptk>n 
10 processes described above. Encryption techniques for 
networks are well known, and so will not be described 
in any further detail In this specificatk>n. 

Some possible modifications 

IS 

It will be appreciated that many modifications may 
be made to the system described above without depart- 
ing from the scope of the present inventkxi. For exam- 
ple, instead of using the same encryptbn algorithm for 

20 all the tables, a different encryptkwi algorithm may be 
used for each table. 

The login procedure may be enhanced with some 
sort of software for user authenticat ton. This process will 
invoh^e an extra database server. It is envisaged that the 

2S authentication process will, on a positive authentication, 
return the encryptton key or keys to be used by the client 
applicaton to calculate the required PIDs. 



omputer system comprising: 

(a) a server having a database including at 
least one personal information table and at 
least one further table containing information 
relating to persons whose details are stored in 
the personal infonmation table; and 

(b) a plurality of clients, for accessing saki da- 
tabase; characterised in that 

(c) said tables in said database have keys that 
are unrelated to each other, whereby it is im- 
possible to determine solely from information In 
the server whbh record in said further table cor- 
responds to which record in said personal in- 
fornnation table; and 

(d) each client includes an encryption process 
for converting a personal kientrfier value, which 
identifies a record relating to a particular person 
in said personal information table, into a pseu- 
do-Identifier value, which identifies a record re- 
lating to the same person in said further table. 

2. A computer system according to Claim 1 wherein 
said encryption process uses a different encryptton 
protocol for each said pseudo-identifier value. 

3. A computer system according to Claim 2 wherein 
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the encryption process uses the tollowing parame- 
ters: 

the personal identifier value being encrypted, 
an encryption key. and 
a unique identifier number for the pseudo-iden- 
tifier. 

4. A computer system according to any preceding 
claim wherein the database includes at least one 
free text table containing free text information, and 
wherein said client includes means for encrypting 
text before writing it into said free text table and for 
decrypting text when read from said free text table. 

5. A computer system according to any preceding 
claim including means for encrypting information 
while in transit between said client and said server. 



10. 



said client encrypts text before writing it Into said 
free text table and decrypts text when read from 
said free text table. 

A method according to any of Claims 8-9 wherein 
information is encrypted while In transit between 
said client and said server. 
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6. A method of securely storing data in a database, 
comprising: 

(a) storing in a server a database Including at 
least one personal information table and at 
least one further table containing Information 
relating to persons whose details are stored in 
the personal information table; 

(b) providing said tables with keys that are un- 
related to each other, whereby it is impossible 
to determine solely from information in the serv- 
er which record in said further table corre- 
sponds to which record in sakJ personal infor- 
mation table; 

(c) operating a plurality of clients to access said 
database; and 35 

(d) performing, in each sakJ client, an encryp- 
tion process which converts a personal Identi- 
fier value, identifying a record relating to a par- 
ticular person In said personal Information ta- 
ble, into a pseudo-Identifier value, which iden- 40 
titles a record relating to the same person in 
said further table. 

7. A method according to Claim 6 wherein a different 
encryptkjn protocol is used for each sakJ pseudo- ^ 
Identifier value. 

8. A method according to Claim 7 wherein said encryp- 
tion process uses the following parameters: 

50 

the personal identifier value being encrypted, 
an encryption key. and 

a unique identifier number for the pseudo-iden- 
tifier. 

55 

9. A method according to any of Claims 6 to 8 wherein 
said database includes at least one free text table 
containing free text information, and wherein each 
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